- HTTP 메시지는 HTTP 애플리케이션 간에 주고받은 데이터의 블록
- 데이터의 블록은 메시지의 내용과 의미를 설명하는 텍스트 메타 정보로 시작하고 선택적으로 데이터가 올 수 있음
- 메시지는 클라이언트, 서버, 프락시 사이를 흐름
- 인바운드: 메시지가 원서버로 향하는 것
- 아웃바운드: 모든 처리가 끝난 뒤 메시지가 사용자 에이전트로 돌아오는 것
- 모든 메시지는 다운스트림으로 흐름
- 발송자는 수신자의 업스트림
- 메시지는 시작줄, 헤더 블록, 본문 세 부분으로 이루어짐
- 시작줄은 어떤 메시지인지 서술, 헤더 블록은 속성을, 본문은 데이터를 담고 있고 본문은 아예 없을 수 있음
- 시작줄과 헤더는 줄 단위로 분리된 아스키 문자열
- 각 줄은 캐리지 리턴(ASCII 13)과 개행 문자(ASCII 10)로 구성된 두 글자의 줄바꿈 문자열로 끝남(줄 바꿈 문자열 'CRLF')
- 본문은 시작줄과 헤더와 달리 비어있을 수도 있고 텍스트, 이진 데이터를 포함할 수 있음
- 요청 메시지
<메서드> <요청 URL> <버전> <헤더> <엔터티 본문> - 응답 메시지
<버전> <상태 코드> <사유 구절> <헤더> <엔터티 본문>
메서드클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작 ex) POST, GET 등요청 URL요청 대상이 되는 리소스를 지칭하는 완전한 URL 혹은 URL 의 경로 구성요소버전지원하는 가장 높은 HTTP의 버전, HTTP/<메이저>.<마이너>상태 코드요청 중 무엇이 일어났는지 설명하는 세 자리 숫자. 첫번째 자릿수는 성공, 에러등을 나타냄 ex) 404사유 구절(reason-phrase)상태 코드의 의미를 사람이 이해할 수 있게 설명하는 짧은 문구헤더들이름, 콜론, 선택적인 공백, 값, CRLF 가 순서대로 나타나는 0개 이상의 헤더들.엔터티 본문임의의 데이터 블록. 생략 가능
요청줄서버에게 리소스에 대해 해달라고 부탁하는 줄응답줄수행 결과에 대한 상태 정보와 결과 데이터를 클라이언트에게 돌려주는 줄
일반 헤더요청과 응답 양쪽에 모두 나타날 수 있음요청 헤더요청에 대한 부가 정보 제공응답 헤더응답에 대한 부가 정보 제공Entity 헤더본문 크기와 콘텐츠, 혹은 리소스 그 자체 서술확장 헤더명세에 정의되지 않은 새로운 헤더- 긴 헤더 줄은 최소 하나의 스페이스 혹은 탭문자를 통해 여러 줄로 쪼개서 더 일기 좋게 만들 수 있음
- HTTP 메시지의 화물
- 이미지, 비디오, HTML 문서 등 여러 종류의 디지털 데이터 실어 나를 수 있음
- 요청과 응답 메시지의 시초이자 훨씬 단순한 프로토콜로 구성되어 있음
- 모든 서버가 모든 메서드를 구현하지는 않음
- 메서드는 대부분 제한적으로 사용됨
- 안전한 메서드란 해당 메서드를 사용하는 HTTP 요청의 결과로 서버에 어떤 작용도 없음을 의미
- 안전한 메서드가 서버에 작용을 유발하지 않음을 보장하진 않음
- 가장 흔히 사용되는 메서드로 서버에게 리소스를 요청할 때 사용함
- HTTP/1.1 은 서버가 이 메서드를 구현할 것을 요구함
- GET처럼 행동하지만 서버가 응답으로 헤더만을 돌려줌
- 리소스 없이도 리소스에 관한 정보(ex.타입)를 알아낼 수 있음
- 상태 코드를 통해 개체의 존재 여부 확인 가능
- 헤더를 확인해 리소스 변경 여부 확인 가능
- 서버 개발자는 GET 으로 얻는 것과 정확히 일치함을 보장해야 하고 HTTP/1.1 준수를 위해 HEAD 메서드 구현해야 함
- 서버에 문서를 쓰고, 교체하기 위해 사용함
- PUT 은 콘텐츠를 변경할 수 있게 해주기 때문에 수행 전, 사용자에게 비밀번호를 요구하는 경우가 많음
- 서버에 입력 데이터 전송하기 위해 설계됨
- 클라이언트에게 요청이 서버에 도달했을 때 어떻게 보이는지 알려주는 용도로 사용함
- 목적지 서버에서 루프백(loopback) 진단을 시작해, 요청메시지를 본문에 넣어 응답으로 되돌려줌
- 주로 의도한 요청/응답 연쇄를 거치는지 검사하는, 진단의 용도로 주로 사용
- TRACE 요청은 어떤 엔티티 본문도 보낼 수 없음
- 웹 서버에게 여러가지 종류의 지원 범위를 물어볼 때 사용
- 요청 URL 로 지정한 리소스에 대한 삭제를 요청할 때 사용
- 단 HTTP 명세는 서버가 클라이언트에게 알리지 않고 요청을 무시하는 것을 허용하기 때문에 삭제가 수행되는 것을 보장하진 않음
- HTTP 는 필요에 따라 확장해도 문제가 없도록 설계되어 있음
- LOCK, MOVE, COPY 등 의 확장 메서드가 있음
- 확장 메서드를 정의했을 때 대부분의 HTTP 애플리케이션이 이해할 수 없음에 주의
- 프락시는 종단 간 행위를 망가뜨리지 않을 수 있다면 알려지지 않은 메서드가 담긴 메시지를 다운스트림 서버로 전달하려 시도함
- HTTP/1.1 에서 도입
- 클라이언트와 100 Continue
- 요청의 시작 일부가 받아들여졌고 클라이언트가 나머지를 계속 이어서 보내야 함을 의미
- 서버가 다루거나 사용할 수 없는 큰 엔터티를 서버에게 보내지 않으려는 목적으로만 사용해야 함
- 서버가 100 Continue 응답을 보내주길 막연히 기다려서는 안되고 약간의 타임아웃 후에는 그냥 엔터티를 보내야함
- 서버와 100 Continue
- 서버는 100 Continue 응답을 의도하지 않은 클라이언트에게 100 Continue를 보내선 안됨
- 어떤 이유로 인해 엔터티의 일부(혹은 전체)를 수신했다면 클라이언트는 이미 계속 전송하기로 결정했기 때문에 서버는 이 상태 코드를 보낼 필요가 없음
- 100 Continue 응답을 의도한 요청을 받고 엔터티 응답을 읽기 전에 요청을 끝내기로 결정했을 때 서버가 그냥 응답을 보내고 연결을 닫으면 클라이언트가 응답을 받을 수 없게 됨. 따라서 그냥 응답을 보내고 연결을 닫아서는 안됨
- 프락시와 100 Continue
- 100 Continue 응답을 의도한 요청을 받을 경우, 다음 홉 서버가 HTTP/1.1을 따르거나 어떤 버전을 따르는지 모른다면 Expect 헤더를 포함시켜 요청을 전달해야 함
- HTTP/1.0이나 이전 버전을 따르는 클라이언트를 대신하여 Expect 헤더와 100 Continue 값을 포함시키기로 결정했다면 클라이언트는 모르는 일이므로 응답을 전달해선 안됨
- 클라이언트의 요청에 성공했음을 의미하는 상태 코드들
- 클라이언트에게 리소스 이동 여부를 알려주거나 다른 대안 응답을 제공해주는 상태코드들
- 302, 303, 307 에 중복되는 부분이 있는 이유는 버전에 따라 상태 코드를 다루는 방식에 차이점이 있기 때문
- 가장 적절한 상태 코드 전달을 위해 클라이언트의 HTTP 버전을 검사해야 함
- 서버가 다룰 수 없는 무언갈 보냈을 때에 대한 응답을 제공해주는 상태코드들
- 클라이언트의 올바른 요청임에도 불구하고 서버 자체적인 에러가 발생했을 때에 대한 응답을 제공해주는 상태 코드들
- 클라이언트와 서버 양쪽 모두가 사용
- 메시지에 대한 아주 기본적인 정보를 제공함
- 일반 캐시 헤더 - HTTP/1.0 은 매번 원 서버에서 객체를 가져오지 않고 로컬 복사본으로 캐시할 수 있도록 도와주는 캐시 해더를 도입
- 서버에게 클라이언트가 받고자 하는 데이터 타입을 알려줌(ex.
Accept: */*) - 조건부 요청 헤더 - 요청에 응답하기 전에 조건이 참인지 확인하는 제약을 포함시키기 위한 헤더
- 요청 보안 헤더 - 리소스에 접근하기 전에 자신을 인증하게 하는 헤더
- 프락시 요청 헤더 - 프락시 기능을 돕기 위한 헤더
- 클라이언트에게 정보를 제공하기 위한 자신만의 헤더(ex.
Server: Tiki_Hut/1.0) - 협상 헤더 - 협상 가능한 리소스에 대한 정보를 운반하는 헤더
- 응답 보안 헤더 - 기본적인 인증요구 헤더
- 엔터티 본문에 대한 헤더(ex.
Content-Type: text/html; charset=iso-latin-1) - 콘텐츠 헤더 - 콘텐츠에 대한 구체적인 정보 제공
- 엔터티 캐싱 헤더 - 언제 어떻게 캐시가 되어야 하는지에 대한 지시자 제공
- 비표준 헤더로, HTTP 프로그램은 의미를 몰라도 용인하고 전달해야할 필요가 있음